I’m seeking DTS guidance on supported ScreenCaptureKit usage and diagnostics for an intermittent authorization failure, filed as FB24757092.
Captured evidence (my incident)
On macOS 26.6.2 (25G83), Apple silicon, an already-authorized custom Apple Development-signed AltTabDebug build encountered renewed Screen Recording prompts. Unified logs show root tccd exhausting file descriptors during authorization. Three failing tccd processes each reported 255 total descriptors, with 250 unique descriptors referring to the same app executable. SecStaticCodeCreateWithPath failed with error 100024 (UNIX[Too many open files]); tccd could not match the existing kTCCServiceScreenCapture code requirement, and replayd reported TCC Disallow / user denied for captureScreenshot. Later checks allowed the same running app again.
This confirms resource exhaustion and authorization failures. It does not establish why descriptors accumulated, a persistent leak mechanism, a per-capture leak rate, or a deterministic reproducer. The reported load spike and roughly one-second display freeze have an uncertain causal relationship to these failures. I have not established reproduction on macOS 27 or descriptor exhaustion in an unmodified release build. No incident-time sysdiagnose was collected.
Separate upstream observations
The AltTab maintainer reported testing the signed release in /Applications on the same OS build: 446 screenshots produced 1,350 ScreenCapture authorization requests, with repeated code-signature validation; approximately 23 ms of root-tccd CPU per thumbnail was reported. These are the maintainer’s measurements, not independently repeated by me, and do not measure descriptor growth per capture.
https://github.com/lwouis/alt-tab-macos/issues/6025
https://github.com/lwouis/alt-tab-macos/issues/6025#issuecomment-5640382131
Questions
Is there a supported ScreenCaptureKit capture pattern, request concurrency/rate guidance, or recovery strategy to reduce repeated authorization work and avoid renewed prompts when code validation fails from transient resource exhaustion?
How should an app distinguish a genuine permission denial from an unavailable/failed authorization service, without repeatedly requesting permission?
Which logging profile, trace, or incident-time diagnostics should we collect to correlate capture submissions/completions with tccd descriptor lifetime and isolate the accumulation mechanism?
FB24757092 contains the focused timeline, descriptor dumps, prompt screenshot, and separately attributed maintainer findings. Raw diagnostics and private system/account information are intentionally omitted here. I built a standalone Swift/AppKit probe that uses one retained SCContentFilter per batch, logs submissions and actual callbacks, bounds outstanding requests, stops new submissions on the first error, and discards images. On macOS 27.0 (26A428), its ad-hoc-signed build captured its own window successfully in 446-request captureScreenshot batches at concurrency 1 and 4. This validates the harness, not reproduction of the original failure. The code-level form requests a focused project demonstrating the issue; this probe does not yet reproduce exhaustion. Could DTS advise the next isolation step and whether a private support case is appropriate for the existing evidence?
0
0
27